Description

Remove and disable the local development mode completely.

The file pubspec_overrides.yaml exist so we can override the dependencies to use the local ones instead from pub.dev

We usually don't want that in production, so it's only during development to allow contributors to focus on the changes instead having to update the minimum change of flutter_quill by first introducing the internal breaking changes, upload a version so we can use it in the version after it as a minimum for flutter_quill_extensions (See 10.7.2) as an example.

Contributors had to include the dependency_overrides and then remove it before pushing a commit, sometimes they push a commit to test the changes in CI. I introduced the pubspec_overrides.yaml.disabled which will be ignored by pub.dev (as it uses pubspec_overrides.yaml instead) and two scripts which will create pubspec_overrides.yaml files and delete them (which is ignored in .gitignore).

I don't see a strong reason for this feature, if we need to fix something we should do it manually and ensure a compatible minimum version requirement, we also usually test using the example app so it's usually enough to have it there.

Also, I see some other issues of having only one version for all packages, dart_quill_delta should have its own version separated from flutter_quill. Same to flutter_quill_test as it didn't introduce any changes. The flutter_quill and flutter_quill_extensions might or might not require only one version.

• When we want to introduce breaking changes to one package, we have to break them all
• When a minor version made to a package, we have to publish them all over again
• They will all share the same CHANGELOG.md which is not very organized (see Improve quality and format of CHANGELOG.md #2211).
• It gives us some limitations when introducing internal breaking changes. We will always have to make some internal changes backward compatible between flutter_quill and flutter_quill_extensions. When a new API introduced in flutter_quill and it's needed in flutter_quill_extensions, with our current workflow, we have to release it in backward compatible way even if it's an internal API first, once we have the new version of flutter_quill, we need another release that increases the minimum version of flutter_quill in flutter_quill_extensions
• The current workflow doesn't give us the flexibility when publishing the packages in the correct order, there is no specific order that we must stick to.
• We don't want to fix this issue between flutter_quill and flutter_quill_extensions, when a breaking change is introduced, users expect improvements and new features to the final product, so we should enhance flutter_quill_extensions and once there is a strong reason to introduce a breaking change by fixing issues, introducing features and more tests then we will probably introduce it, fixing it requires a separate package of flutter_quill_extensions and that's not a priority at the moment.
• This whole workflow is not scalable enough to have quill_native_integration with its own packages (quill_native_integration_platform_interface, quill_native_integration_web, quill_native_integration_windows etc...). See feat: Use quill_native_bridge as default impl in DefaultClipboardService, fix related bugs in the extensions package #2230 for more details.
• We don't want complexity that doesn't fix a issue, especially with our current situation.

As for quill_native_bridge, I will also separate the version, I need to publish a new package and deprecate this, luckily it's already experimental and for internal use so shouldn't be a breaking change as we didn't expose the APIs of it yet (see #2230). The new package will probably be quill_native_integration.

Related Issues

Type of Change

• ✨ New feature: Adds new functionality without breaking existing features.
• 🛠️ Bug fix: Resolves an issue without altering current behavior.
• 🧹 Code refactor: Code restructuring that does not affect behavior.
• ❌ Breaking change: Alters existing functionality and requires updates.
• 🧪 Tests: Adds new tests or modifies existing tests.
• 📝 Documentation: Updates or additions to documentation.
• 🗑️ Chore: Routine tasks, or maintenance.
• ✅ Build configuration change: Changes to build or deploy processes.